Page history of 이콜레모 2015년 회고

2015년은 지금까지 이콜레모의 역사에서 한 가지 목표만을 끝까지 유지한 첫번째 해였다. 실제로 그 목표를 시작한 것은 작년 하반기라서 1년 5개월 정도 이어온 셈. 그만큼 이전까지의 이콜레모는 전략적으로 형편 없었다는 뜻이 되겠다. 이전에도 이콜레모가 외주를 많이 했고, 중간중간에 재미 있었던 순간도 많았지만, 총체적으로 유쾌한 경험이었다고는 할 수 없었다. 다음은 그런 고민들이 담겨 있는 글들이다.

이콜레모 외주 실패의 역사

• 일기장/2009-02-27 우리는 프로젝트의 성공을 원하지만, 고객은 프로젝트의 완료를 원한다.
• 일기장/2009-05-03 대기업의 횡포
• 일기장/2009-05-11 적당히 외주해서 돈 모은 다음에 우리 아이템 하자는 전략의 허구성
• 일기장/2009-11-04 창업 이념을 잃고 돈에 휘둘린 시간
• 일기장/2009-12-14 이젠 돈에 휘둘리지 말아야지
• 일기장/2010-05-24 갑질 고객을 미리 판별할 수 있을까?
• 일기장/2010-05-16 좋은 외주 고객에 대한 나름대로 생각해본 조건

뭐 구질구질 많지만, 요약하면 제대로 외주하는 것도 아니면서 돈에 휘둘리기는 했고, 좋은 고객을 필터링하기 위해 열심히 회고하고 분석했으나 다 소용 없었다는 이야기다. 그래서 재작년에 다시 외주를 시작할까 아니면 아예 새로운 길을 찾을까 고민을 많이 했었다. 그러다가 새로운 시스템으로 외주를 해보기로 마음을 먹었다. 그 시스템은 바로 시간제 보수 시스템이다.

시간제 보수 시스템의 배경

이 시스템을 선택하는데 영향을 주었던 것들은 이런 것들이다.

• 변호사, 세무사 등은 시간당 상담료를 받는다.
• XP에서 이야기하는 외주 프로젝트에서의 pay per use 개념
• 자신이 원하는 수준에 따라 개발 비용이 차이가 난다는 것을 알게 되면 고객도 더 합리적으로 행동하려고 하지 않을까?
• 소프트웨어 견적의 불합리성
• 프로그래머도 노동자인데 노동 가치로 돈을 받는 것이 합리적이지 않을까?
• 몇 번의 짧은 취업 경험에서 내 시장 가치가 꽤 괜찮다는 것을 알게 됨.
• 어차피 내 마음에 드는 소프트웨어를 외주에서 만들 수 없다면 그에 상응하는 돈이라도 받자.
• 지섭이에게서 배운 연봉 협상 전략 - 원하는 금액을 스스로 정하고 그 금액을 주는 회사를 만나기 전까지 타협하지 말라.
• 공인 단가대로 제대로 받을 수만 있다면 먹고 사는데는 문제 없다.

프로그래머의 수급 불균형

연봉 협상 전략은 지섭이가 자기가 원하는 연봉을 정해놓고 취업하는 과정을 보고 배운 것이다. 옆에서 지켜보니 연봉은 자기가 원하는 금액에 다소 못 미치지만 그 외의 조건들을 생각해보면 괜찮아보이는 건들이 여럿 있었는데 지섭이는 계속 거절했다. 솔직히 지섭이가 저러는 걸 보기 전까지의 나라면 저러다 영영 취직 못할까봐 겁나서 못했을 거다. 근데 이 녀석은 꿋꿋이 밀고 나가더니 결국 원하는 조건의 일자리를 찾았다. 뭐 그 뒤로 오래 일한 것 같진 않지만;;

그래서, 나도 이콜레모를 잠정 중단하고 취업을 해볼까 하던 시기에 이 전략을 채용했다. 근데 조금 더 나아갔다. 협상이 한 번 실패할 때마다 희망 연봉을 1천만원 올리기. 이렇게까지 할 수 있었던 것은 지섭이를 지켜보면서 용기를 얻게 된 것도 있고, 또 그 사이 프로그래머 수요가 더 늘어나서 공급을 크게 초과하고 있다는 사실도 눈치 챘기 때문이다. 항상 시장 원리에 당하기만 해왔던 노동자 입장이지만 시장 상황이 변하면 역으로 이용할 수 있는 것도 당연하다.

그래서 네 번 협상을 실패하고 다섯 번째에 내가 원하는 조건으로 취직을 성공했다. 나 역시 지섭이처럼 거기에 오래 머무르진 못했지만, 여튼 이 경험은 고급 프로그래머의 수급 상황에 대한 확신을 가질 수 있었다. 그래서 내가 지금도 다른 프로그래머들에게 이런 조언을 한다. 

네가 원하는 조건을 양보하지 말고 끝까지 버텨라. 네가 정말 실력이 있다면 너를 찾는 곳은 반드시 있다. 

찾는 곳이 없으면 나에게 오라. 내가 일거리를 주겠다.

소프트웨어 견적의 불합리성

위에서 이야기한 것이 내가 용기를 낼 수 있었던 이유라고 한다면, pay per use의 개념은 이 시스템이 더 합리적이라고 생각하는 이유다. 아니, 반대로 소프트웨어 견적의 불합리성이라고 해도 좋겠다. 소프트웨어 프로젝트를 미리 견적을 낸다는 것 자체가 말이 안되는 개념이다. 아직 소프트웨어 개발이 얼마나 걸릴지 예측할 수 있는 프로그래머는 태어난 적이 없다.

소프트웨어 개발을 시작하기도 전에 미리 견적을 내서 비용을 고정하고 프로젝트를 하면 갑과 을은 어떻게 행동하게 될까? 갑은 최대한 작은 견적을 받아서 계약하려고 할 것이고, 을은 최대한 부풀리려고 할 것이다. 여기까지는 좋다. 시장이니까. 근데 문제는 계약한 후에 일어난다. 계약한 후에 갑의 행동은 어떻게 될까? 갑은 이미 비용이 고정되어 있으니 최대한 많은 기능을 집어넣으려고 한다. 그게 이익이라고 생각하니까. 그러면서도 이미 약속했던 기능이 안되는 사실은 참을 수 없다. 손해니까.

을은 당연히 정반대로 행동한다. 이미 받을 비용은 정해져 있으니까 최대한 적은 노동을 해주는 게 이익이므로 고객과의 협상은 늘 일의 양을 줄이는데 초점이 맞춰진다. 물론 가끔은 을의 담당자가 자기 회사의 프로그래머보다 갑을 만족시키는 것을 중요하게 생각하는 경우가 있는데, 이 경우는 을의 담당자가 갑 역할이 되고 프로그래머들이 을 역할이 되기 때문에 문제가 쉬프트되긴 해도 그대로 존재한다. 어쩌면 이게 많은 프로그래머들의 현실일 것이다. 팀장은 갑님 앞에서 예스맨이 되어 굽실거리다 회의 끝내고 와서는 프로그래머들을 몰아세우는 상황. 

이런 것 뿐만이 아니다. 예를 들어 내가 고객의 요구를 아주 멋지게 만족시켜줄 수 있는 방안이 생각났는데 이미 계약한 금액이 턱없이 모자란다. 그럼 내가 그 아이디어를 말할까? 반대로 고객이 자기도 처음에 원했던 기능 중에 하나가 이제 필요 없다는 것을 알았는데, 이거 안해도 된다고 할까? 하든 안하든 비용 지불하는 건 똑같은데? 다행히 지혜로운 고객들도 종종 있고, 그들은 그게 결과적으로 자신들에게도 이득이라는 것을 알기 때문에 필요 없는 것은 처음에 하기로 했더라도 빼자고 하는 경우가 있다. 하지만, 대부분은 이게 손해보는 느낌이 드는지, "그래도 하기로 했잖아요"하면서 끝까지 요구하는 경우가 많다. 아니면 그 대가로 다른 걸 넣어달라고 하거나.

이처럼 고정 비용 하에서는 갑과 을의 이해 관계가 상충되기 때문에 이 소프트웨어를 어떻게 하면 잘 만들어야 할까 둘이 머리를 맞대고 고민을 해야 할 중요한 회의 시간에 이 일을 뺄까 더할까로 싸우게 된다. 프로젝트가 잘 되려면 둘이 협력을 잘 해야 할 텐데 말이다. 근데, 애자일 선언의 세번째 가치가 뭐더라?

Customer collaboration over contract negotiation

나는 이걸 하고 싶은 거다. 그렇다고 해서 손해를 보면서 일할 생각은 눈꼽만큼도 없다. 그럼 답은 간단하다. 일한 만큼 돈을 받으면 된다.

일한 만큼 돈을 받으면 고객이 아무리 무리한 요구를 하더라도 그만큼 돈을 받으니까 나는 손해를 보지 않는다. 그러면 나도 열린 마음으로 고객의 문제 해결에 집중할 수 있게 된다. 근데 여기까지 해주면 내가 손해고, 저기까지 해주면 내가 이익이고 이런 생각을 해야 하는 상황이 오면 집중이 될 리 만무하다. 예전의 이콜레모는 다소 손해를 보더라도 고객에게 좋은 기능을 탑재해주는 것을 우선하기도 했는데, 그 결과는 적자는 도저히 유쾌하게 받아들일 수가 없었다.

노동가치가 부가가치보다 중요하다

프로그래머의 성과는 유독 노동가치보다 부가가치로 평가하려는 경향이 있다. 소프트웨어는 들어간 노력보다 훨씬 큰 부가가치를 창출하는 경우가 많으니 그 부가가치를 나누어 받아야 하는 것 아니냐는 논리다. 주로 노임 단가제도를 비판하는 논거로 많이 등장한다. 하지만, 이건 자본가의 논리다. 그럼 만일 개발한 소프트웨어가 아무 가치를 창출하지 못하면 프로그래머는 돈을 받지 않아도 되는가?

내가 투자 받는 스타트업을 안하려는 이유도 비슷한 맥락이다. 스타트업이 투자를 받고 성공을 이루게 되면 자본가의 권력이 더 강화된다. 투자한 자본가들이 돈을 더 많이 벌기 때문이 아니다. 성공으로 얻는 부는 창업가들 본인이 더 클 수도 있다. 문제는 스타트업이 점점 더 투자에 의존하게 된다는 것이다. 이건 두 가지 현상으로 나타나는데, 하나는 창업자와 투자자의 힘의 균형이 점점 더 투자자에게로 이동한다는 것이다. 이건 국내 상황에서도 흔하게 보이는 모습이다. 그리고 사실 더 중요한 것은 두번째인데, 자본이 부족한 창업자들이 투자 받은 스타트업과 경쟁에서 이기는 것이 어렵기 때문에 실질적으로 자본의 중요성이 점점 더 커진다는 것이다. 물론 두번째 현상은 다시 첫번째 현상을 강화하게 된다.

말하자면 머니볼과 같은 효과다. 초기의 머니볼은 자금이 넉넉하지 않은 구단이 데이터 분석을 통해 부자구단과 경쟁할 수 있는 힘을 키우는 수단이 되었지만, 결국 그 방법이 알려지면서 부자 구단이 오히려 그 수단을 더 잘 활용해서 결국은 다시 자본 게임이 되고 말았다. 스타트업에도 유사한 일이 일어나고 있는데, 이제 개인 창업자가 혼자 뚝딱뚝딱 제품 만들어서 성공시키기는 어려운 세상이 되었다. 자본의 힘을 등에 엎은 속도전에서 경쟁하기 어렵기 때문이다. 그래서 스타트업에서도 초기에 좋은 창업자를 모으는 것보다 투자를 확보하는 것이 더 중요한 일이 되고 만다. 물론 VC들은 입만 열면 좋은 팀이 갖춰져야 투자한다고 말하지만, 실제 VC들은 좋은 팀인지 아닌지 여부를 판단할 눈도 없거니와, 더 중요한 것은 첫번째 투자를 유치한 이후다. 첫번째 투자를 유치한 이후에 창업자들은 돈이 있는 상황이 되기 때문에 직원과의 관계에서 스스로가 갑의 위치에 올라선다고 생각하게 된다. 투자 받은 후에 핵심 프로그래머가 경영진과의 불화로 나가는 모습을 우리는 얼마나 많이 보아왔는가? 돈이 있으면 다시 더 좋은 사람 고용할 수 있다고 생각하게 된다. 물론 실제로 더 나은 사람을 구하는 경우는 거의 없고 제대로 된 후임을 구하지 못해 뒤쳐지거나 망하는 경우가 훨씬 많긴 하나, 어쨋든 이 시점부터 자본 권력이 노동 권력을 추월하게 되는 사실은 변함이 없다.

스타트업에서 대박이 났을 때 CEO는 수천 억씩 벌어가는데 전화상담원은 여전히 180만원 월급 받는 세상이 합리적인 세상인가? 그 CEO가 없었다면 성공할 수 없었겠지만, 전화상담원이 없었어도 성공할 수 없었다. 대체 가능한 인력이라는 점이 노동의 가치를 지나치게 떨어뜨리는 이런 현실이 싫다. 노동은 좀더 신성한 것이어야 한다.

나도 이런 현상을 뒤집을 해법을 갖고 있는 것은 아니다. 나 스스로도 돈만 있으면 뭐든지 성공시킬 수 있다고 자신하는 종자인데, 자본의 위력을 부정하기는 쉽지 않다. 다만, 내가 그런 현상을 가속화하고 싶지는 않은 것이다. 

내가 바라는 좀더 바람직한 세상은 프로그래머들이 그냥 자신의 능력에 맞는 고정 급여를 받으면서 일할 수 있는 세상이다. "능력에 맞는"이라는 것도 비례한다는 뜻은 아니다. 이를테면 프로그래머의 생산성 차이는 40배까지 날 수 있다고 하고, 이콜레모에서 고용하는 프리랜서들의 기준으로는 최대 5배 정도의 차이가 나는 것으로 추정되지만 이콜레모에서 고용하는 프리랜서간 급여의 최대 차이는 2.5배에 불과하다. (황지섭 같은 고수를 고용할 때는 예외) 

그래서, 시간제 보수 시스템은 내가 만들어낸 가치에 비례해서 돈을 받는 것이 아니라, 내가 노동한 시간에 비례해서 돈을 받는 시스템이다. 물론 그렇게 받았는데 내가 만들어낸 가치가 평균적으로 시장의 가치보다 작다면 나는 시장에서 퇴출되거나, 혹은 살아남기 위해 단가를 낮추어야 할 것이다. 단가를 내가 정하는 것이니만큼 이것은 내가 받아들여야 할 현실이다. 다만 그렇게 단가가 변하더라도 여전히 부가가치보다는 노동시간에 비례하는 시스템이 되는 것이다. 

이콜레모의 외주 원칙과 그에 따른 변화

이전과 달라진 것은 시간제 보수만이 아니다. 여러 가지로 외주를 하는 원칙이 달라졌는데, 모두 정리하면 이렇다.

• 비용은 투입한 시간에 비례해서 받되, 단위는 하루와 반나절 두 가지만 사용한다.
• 비용을 받는 시간당 단가는 투입한 엔지니어의 역량에 따라 다르게 정하되, 내가 정한다.
• 일정을 다짐하지 않는다.
• 계약하기 전에는 고객을 만나러 가지 않고, 오는 고객만 만난다. (친구, 예전 동료, 동문 등은 찾아가기도 한다.)
• 비용은 매달 정산 받는다.
• 조건만 맞으면 고객을 선별하지 않는다.
• 컨설팅 등의 단기 프로젝트가 아닌, 내가 주도적으로 코딩해야 하는 프로젝트는 동시에 2개 이상 진행하지 않는다.
• 동시에 일을 의뢰하는 고객이 많을 때는 계약까지 먼저 진행하는 고객과 일한다.

찾아오는 사람만 만난다

리스트는 길지만, 간단히 요약하면 시간제 보수에 합의하고 날 찾아와서 일을 의뢰하는 사람하고만 일한다는 것이다. 찾아가지 않기로 한 것은 딱히 내가 거만해서가 아니라 시간제와 연관이 있다. 일하는 시간만큼 돈을 받는 시스템이다보니 공치는 날을 줄여야 한다. 서울에 미팅하러 가면 보통 반나절을 날리게 되는데, 그러면 월 수입의 40분의 1이 줄어드는 것이다. 우리 회사가 크다면 영업 비용으로 그 정도는 감수할 수 있지만, 현재 이콜레모는 내가 전력의 대부분이니 내가 하루 놀면 회사 매출이 하루 분 줄어드는 거라 타격이 크다.

미팅 비용을 따로 받을까 하는 생각도 안해본 건 아닌데, 그건 오라고 하는 것보다 더 받아들일 가능성이 적을 것 같다. 그래서 날 찾아 오는 고객만 만나고, 내가 가야하는 경우는 그냥 거절한다. 찾아오는 것도 되도록 찾아오기 전에 내 조건을 먼저 이야기하고 그걸 받아들일 생각이 있을 때만 찾아오라고 한다. 처음에는 무작정 만나자고 하는 사람들을 다 만났는데, 그러다보니 미팅에서 이야기하다가 내가 조건 이야기하면 바로 거기서 미팅 종료가 되는 경우를 몇 번 겪었다. 그래서 그 뒤로는 서로 시간 낭비를 줄이고자 조건을 먼저 이야기한다.

이 정책을 시행한 이후로 미팅 회수는 엄청나게 줄었다. 평균적으로 일주일에 한두 번 미팅하던 것에서 한 달에 한 번 이하로 줄어든 것. 타격이 있을 법도 한데, 생각보다 타격이 없었던 것은 미팅에서 계약으로 이어지는 확률이 매우 높아졌다. 그래서 나는 나보고 오라고 하는 고객들은 대부분 내가 아니어도 되는 상황이었거나, 그냥 후보를 수집하는 단계였던 게 아니었나 하고 추정한다. 내가 가서 미팅하더라도 계약이 성사될 건이 아니었던 기회들이 사라진 셈이다. 덕분에 나도 일에 좀더 집중할 수 있었고, 올해는 대부분의 시간을 코딩하면서 보낼 수 있었다.

고객을 선별하지 않는다

앞서 이콜레모 외주 실패의 역사에서 보듯, 이전에는 이콜레모가 좋은 고객을 선별해 내기 위해 많은 노력을 기울였었다. 근데 지금에 와서 돌이켜보면 그 많은 회고로 얻어낸 통찰들은 아무런 쓸모가 없었다. 나쁜 고객이 나쁜 이유는 수백 가지였고, 그 중 몇 개를 피해봤자 별 소용이 없었던 것이다.

내가 고객의 아이디어를 좋다고 생각하는지 아닌지도 선별 기준으로 넣지 않는다. 내 생각이 틀릴 수도 있거니와, 설령 나쁜 아이디어라는 높은 확신이 있더라도 나쁜 제품을 만들 권리도 있는 거니까, 고객의 아이디어를 존중한다. 그래서 고객이 아이디어에 대한 의견을 물을 때는 아주 잘될 것 같다거나, 정말정말 될 리가 없다거나 하면 내 의견을 이야기해주지만, 그 외에는 답하지 않는다.

재미있는 것은 이렇게 고객을 필터링해왔던 조건들을 다 제거하고 그냥 돈만 맞으면 일한다는 식으로 하니까 오히려 좋은 고객들만 걸린 것 같다. 일단 돈을 제 때 주지 않는 고객이 사라졌다. 매달 지급을 하다보니 가끔 밀리는 경우는 있었지만, 그런 경우에는 상당히 미안해했고, 예전처럼 배째라는 식으로 나오는 고객은 하나도 없었다. 욕설이나 막말을 하는 사람도 이 시스템을 정착시킨 이후로 1년 5개월 간 한 명도 만나지 않았다.(나는 가끔 막말을 했지만...;;) 갑질하려는 사람도 없었고, 내가 미팅하러 가는 시간도 다 돈이라는 걸 알기 때문인지 대부분의 고객은 미팅하러 오라고 요구하기보다 자신들이 찾아왔다. 같은 돈이면 내가 서울 왕복하느라 두세 시간 길바닥에 쏟을 바에야 그 시간에 코딩하는 게 낫겠지.

그렇다고 내가 항상 오라고 한다거나 하는 역 갑질(?)을 하진 않는다. 그냥 오라고 하면 두 말 없이 간다. 어차피 투입한 시간으로 돈 받는 건데 뭐. 

그리고 시간제 보수라는 시스템 때문인지 회의 시간에 일의 분량으로 줄다리기를 하는 일이 거의 없었다. 좀 무리한 듯한 기능을 요구 받을 때는 그게 얼마 걸릴지에 대한 예상을 말해주면 그냥 접는 경우도 많았고, 접지 않고 그래도 해달라고 하면 그냥 해주면 되니까 그걸로 싸울 필요는 없었다. 그래서 좀더 같은 목적을 보고 아이디어를 같이 짜낼 수 있었던 것 같다.

그렇다고 프로젝트가 항상 효율적으로 굴러간 것은 아니다. 당연히 불필요한 기능을 넣거나 중도 변경을 반복한다거나 하는 일은 계속 발생했다. 아마 스토리 포인트를 추정하면서 플래닝 게임에서 협상을 해본 팀들도 알 것이다. 기획자들이 요구한 기능에 스토리 포인트가 크게 매겨진다거나 하면 스스로 철회하는 일이 많아서 효율이 올라갈 것으로 기대하지만, 그런 일은 대개 스토리 포인트가 없었어도 협상이 가능했을 법한 뻔한 일에 대해서나 일어나고, 본질적인 차이는 별로 없다는 것을.

일정을 다짐하지 않되, 예측은 한다.

드라마 허준의 원작이었던 소설 동의보감을 보면 허준이 이런 말을 한다. "의원은 병을 두고 다짐을 하지 않습니다." 사람들의 예상을 벗어나는 의료 행위를 할 때마다 갑으로부터 확실히 낫게 할 수 있는 방법이냐고 다그침을 받는데, 그 때 허준이 한결 같이 하는 대답이 이것이다. 의원은 최선을 다해 의료 행위를 하나, 결과는 보장할 수 없다는 현실을 말해주는 것이다. 딱 한 번, 자신이 내건 조건을 모두 지킨다면 다짐을 두겠다고 하지만, 거의 강압에 의한 것이다.

프로그래머의 현실도 비슷하다. 구현해야할 내용에 대해 예측을 할 수도 있고, 최선을 다해 일하지만, 일정을 보장할 수는 없다. 그 현실을 받아들이도록 하는 것 뿐이다. 심지어 이것은 거의 시간제 보수에 딸려오는 조건인데도 간혹 시간제 보수는 납득하지만 그래도 확정 일정을 달라고 하는 경우가 있는데, 그 경우도 대체로 거부한다. 

예측을 말해줄 때도 불확실성 자체가 전달될 수 있도록 범위로 이야기한다. 그냥 작업 예상 시간의 평균값이나 중간값을 이야기하면 불확실성이 전달되지 않기 때문에 0.5 ~ 1일이라든가, 1 ~ 7일 같은 식으로 범위를 제시한다. 또, 범위가 넓으면 불확실성이 높은 것인데, 이걸 종종 난이도가 높은 것으로 이해하는 경우가 있어서 난이도도 따로 설명을 덧붙인다. 결제 모듈 연동은 쉬운 작업이고, 잘 될 때는 아주 금방 연동할 수 있지만, 국내 PG사의 문서가 개판이라서 파라미터 맞추면서 테스트하는 시간이 오래 걸릴 수 있어서 빠르면 1일이지만 길면 2주도 걸릴 수 있어요.라든지, 채팅 기능을 붙이는 건 어려운 일이긴 하지만 저는 여러 번 구현한 경험이 있기 때문에 3~4일이면 그럴 듯하게 동작하게 만들 수 있어요, 또는 여기 디자인대로 100% 맞추는 게 어려운 일은 아닌데 잔손이 많이 가기 때문에 5일 정도는 더 걸려요 등등. 이렇게 예측을 범위로 말함으로써 숫자와 불확실성 정보를 담고, 추가로 난이도 정보를 말해주는 것.

굳이 난이도를 말해주는 것은 고객이 다른 개발자를 통해서 크로스 체크를 하는 경우에 대비하는 것이다. 단순히 불확실성이 높다거나, 오래 걸린다고만 말하면 이걸 어렵다고 받아들이는 경우가 많기 때문에, "어, 이거 어려운 거 아니라던데요." 같은 사태가 생길 수 있기 때문이다. 아직 내가 이런 걸 경험한 것은 아니지만, 그 반대의 경우, 다른 개발사의 고객이 나에게 크로스 체크를 요청하는 경우가 많았기 때문에 내 고객도 그럴 수 있다고 추정하는 것이다. 

어쨋든, 예측 자체를 이런 식으로 하면 굳이 일정을 못 박으려는 시도 자체가 많이 줄어든다. 실제로 정확한 일정이 중요한 경우는 거의 없기도 하고. 일정을 정하는 것은 비용 문제 외에도 그 자체로 소프트웨어를 개발하기에 적합한 방식이 아니다.

간혹 나도 허준이 겪었던 강압과 비슷한 상황을 겪기는 한다. 이 때 나도 허준과 비슷하게 내 조건을 완벽하게 지킬 경우에 한해서 일정을 다짐해주겠다고 하는 경우는 있다. 작년에는 하나 일정이 미리 예정되어 있는 프로젝트를 하나 했는데, 다행히 시작 시점은 꽤 여유가 있는 시점이었다. 근데, 중간에 디자인을 하는 과정에서 고객의 취향이 지나치게 개입되면서 늘어지는 바람에 일정 맞추기 어려워졌었다. 딱히 일정을 쪼지는 않았지만 이대로 가면 일정이 어떻게 될지 몰라서 중간에 디자인에 고객이 개입하는 걸 중단하는 조건이 되어야 일정을 맞춰줄 수 있다고 한 적이 있었다. 다행히 고객은 내 조건을 수용했고 정확한 일정에 오픈할 수 있었다. 이 정도가 일정에 대해서 내가 양보하는 한계점이다.